There are many data processing and communication systems in which information must be processed and transmitted securely. Typically, such systems include one or more integrated circuits designed to securely store and process information. Microprocessors for secure data processing or communication are generally known as Secure Processing Units (SPUs). SPUs typically have a secure memory for storing confidential information such as cryptographic keys, and a "cryptographic engine" for implementing algorithms for encryption and decryption of data and keys. A general treatise describing the use and implementation of data encryption is "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems" by R. Rivest, A. Shamir, and L. Adleman, published in Communications ACM, p. 120, February 1978. Another treatise on cryptography is "Privacy and Authentication: An Introduction to Cryptography" by W. Diffie and M. Hellman, published in the Proceedings of the I.E.E.E. Vol. 67, pps. 397-472 (March 1979).
Depending upon the application and the operating environment, each electronic system may have different security considerations. In certain applications, the security of a system is of such overriding concern that it outweighs the concern for the loss of information. For instance, the identifying key or password that a bank customer uses to access a hardware-based electronic transaction system should not be revealed to anyone under any circumstances even though the information such as the key or password value may be lost in the event of a hardware malfunction. Such a loss of information is not as damaging as having the information stolen. Therefore, the SPUs used in such a system should not allow for the export of the identifying key or password from an SPU.
In contrast, a corporation may not desire such a strict security policy. In the event that an employee is temporarily unavailable or leaves the company, the corporation is concerned that it may not be able to retrieve valuable information contained in the employee's computer system, which is locked with the employee's public key and can be unlocked only with the employee's private key. The corporation may want its employees' private keys to be escrowed (i.e., backed up) by some safe and secure process, so that in an emergency it can open the files that have been locked by its employees. In these situations, the SPUs used must allow for the export of private keys for escrowing purposes. U.S. patent application Ser. No. 08/485,816, entitled "Cryptographic Processor With Multiple Key Pairs For User and Device Authentication," filed on Jun. 7, 1995, invented by William B. Sweet, Howard Crompton Herbert, An Van Le, and Bruce Schneier, is hereby incorporated by reference.
Thus, there are many situations in which it is desirable to use the same SPU design, yet have the flexibility to modify security features in accordance with the requirements of the application and environment. For example, if an SPU is used to process extremely sensitive information, it will be prudent to implement a conservative security "policy", e.g., destroying all confidential data (e.g., keys) inside the integrated circuit upon detection of even a small deviation from the established security parameters from which it should operate. On the other hand, if the information is not very sensitive, and it is not convenient to replace the secure integrated circuit, the security policy could be more lenient, e.g., action could be taken only when there is a large deviation from the established security parameters.
Furthermore, there are instances in which even devices within a single system may have diverging security considerations. For example, in Interactive Television (ITV) applications where multimedia information is distributed over communication networks or over CD-ROMs, an SPU located at a media server will have security considerations different from that of an SPU located at a set-top box or a desktop computer. The media server needs the capability to perform certain cryptographic operations, which should not be available to the set-top boxes for security reasons. For example, a cryptographic function for escrowing keys of an SPU by trusted personnel such as security officers at the media server is necessary for backup purposes, but this escrowing function must not be made available to users of set-top boxes. Set-top boxes are presumed to be located in a hostile environment, where some users may turn out to be adversaries who would try to steal the value of the keys through the use of an escrowing function in order to obtain other unauthorized information. Hence, it is desirable to use an SPU which could be configured to satisfy the security considerations of a variety of devices in a system.
Another need for an SPU which allows for customized configuration occurs in the manufacturing of integrated circuits for export to foreign countries. Due to export restrictions, only SPUs which do not support certain cryptographic operations, such as strong encryption, can be exported outside of North America. Therefore, unless an SPU design which supports reconfiguration is used, chip manufacturers would have to design and manufacture different SPUs depending upon whether it was intended for domestic uses or for export purposes. It is desirable to manufacture a single SPU designed for domestic use, but is also modifiable to satisfy export control requirements. This will reduce the production and inventory cost of SPUs significantly. In other words, it is desirable to design and build a single SPU and be able to modify its security features and functions to satisfy the security requirements of various applications.
Hence, depending upon the application, the security considerations of a system may vary significantly. In turn, the parameters within which the SPU of a system must function also vary significantly. However, SPUs are typically designed or preconfigured to function only within the parameters of the security policy of a system. Many SPUs employ a "hard-wired" architecture, which cannot be reconfigured once they have been manufactured.
One problem with a hard-wired architecture is that it is difficult to produce custom security features for low volume applications. The reason for this is that it takes a considerable amount of time and money to design, test, and fabricate an integrated circuit. Consequently, from an economic standpoint, it is difficult to justify building small quantities of secure integrated circuits, each customized for a special environment.
Another limitation of a hard-wired architecture is that SPUs are designed or preconfigured to perform only those functions specified by the security policy of a system. If the security policy were to change over time, the only way to alter the functions of the SPU would be to redesign, test, and fabricate another integrated circuit to satisfy the new security needs. This is an expensive and time-consuming process.
One approach which allows for customized configuration of an SPU depending upon the application with which it is used is through the use of different tables or vectors in Read-Only-Memory ("ROM") for different SPUs, which can enable or disable cryptographic functions. Under this approach, a manufacturer would program the ROM with firmware that implements a customer's specific security needs. A disadvantage with this method is that it does not offer the flexibility of allowing a system administrator to dynamically reconfigure an SPU once it has been installed in the field.
The need for SPUs which allow for reconfiguration in a secure manner even after a device has been installed in the field is clear in today's networked computing environment. Individual devices on a network often have different security concerns. For instances, some devices may need access to certain sensitive databases while other devices should be prohibited from such access. Hence, devices on a network usually have diverse levels of security requirements. Each device may have different restrictions based on the processing options that it is permitted to perform. Furthermore, as circumstances change, the functions that a device may perform may be expanded or deleted.
Likewise, in the ITV application, dynamic configuration of a device after manufacture is invaluable because new threats often appear in a system. To continue maintaining security, a system often needs the ability to respond to new threats encountered in a system. For example, a user in the ITV application may discover a weakness in the system which allows him to modify billing data in a set-top box to avoid payments to the service provider. Under such circumstances, there is a need for a method to allow the service provider to dynamically disable one or more relevant functions in all of the set-top boxes so that other users cannot further exploit the weakness. Once the function is disabled, the service provider can make arrangements to recall the set-top boxes in an orderly fashion for replacement or upgrading without the fear that the weakness in the system will be further exploited.
Thus, in addition to the need to modify an SPU for specific applications, it is also desirable to develop a technique which allows for dynamic configuration of an SPU even after it has been installed in the field. This is particularly necessary as the operating environment of computing systems change.
The idea of reconfiguring a device or extending capabilities of a device has been used in the area of general purpose computing systems, such as microcomputers. For such systems, a wide range of memory devices may be employed to allow system capability to be reconfigurable. These devices range from PROM to EEPROM. However, such systems typically use a design which gives technically capable users the ability to enable or disable a particular function, or even to upgrade the firmware (e.g., upgrading the BIOS) of certain components. This is not desirable for cryptographic devices which have specific security concerns.
An approach which allows for reconfiguration of a cryptographic device is set forth in U.S. Pat. No. 5,164,988, entitled "Method to Establish and Enforce A Network Cryptographic Security Policy In A Public Key Cryptosystem." The '988 patent describes a method to modify and enforce the security policy of a network through the use of a "configuration vector." Under this approach, the configuration vector, which specifies the functions a device can perform, is loaded into the device on the network. This configuration vector should only be modified by a network manager or certification authority (CA) as the operating environment changes. To enforce the security policy of the system, the CA would perform a random audit on the cryptographic devices on the network from time to time. During this audit process, the CA would typically request the device being audited to send a copy of its configuration vector, digitally signed by a special private key called device authentication key, which is unique to each device. The signing process is performed securely inside the protected boundaries of the cryptographic device. This device authentication key is registered with the CA when the device is installed and initialized. This key cannot be duplicated, and a new key value will be created every time a device is reinitialized. In the event that an adversary attempts to breach the security policy by loading a modified configuration vector to assign unauthorized capabilities to the device, the CA would discover the unauthorized configuration vector when it audits the configuration vector used in the device. During the audit process, the modified vector would be signed by the device authentication key and transmitted to the CA. When the CA receives the modified vector, it will compare the table with the original table assigned to this device and thus detect the modifications. If, at audit time, the adversary attempts to change the unauthorized configuration vector back to the original value assigned by the certification authority, the adversary would have to reload the original vector, which is possible only if the device is reset to an initial state under this approach. However, after resetting the device, a new device authentication key (used to sign the configuration vector before the it is transmitted to the certification facility) will be generated, replacing the original authentication key. The new key would not be recognized by the certification authority. Thus, any attempt to modify the configuration vector would be detected by the CA through an audit.
However, the method described in the '988 patent has at least two disadvantages. First, although the method allows for dynamic configuration, in replacing an existing configuration vector with a new one, it requires a device to be re-initialized, resulting in a major disruption to operations. Second, unauthorized modifications to the configuration vector could be made at anytime and would not be detected until the system administrator performs an audit. By the time the breach of security is detected, significant damage could have already occurred. Thus, the prior art does not offer the security and flexibility required for today's computing environment.